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(57) Abstract The present invention provides a method and 
system to facilitate peer-to-peer instant message communications 
among users connected to different instant messaging systems. 
To do so, the present invention provides a Single Name Instant 
Messaging Protocol (SNIP) that uses the universal namespace of 
e-mail to facilitate peer-to-peer instant message communications 
among users connected to different networks. Another aspect 
of the present invention is to use the Single Name Instant 
Messaging protocol to authenticate a user over the Internet to 
provide online fraud protection when using a credit card. To 
do so, a method and system according to one embodiment of 
die present invention includes a database that references a credit 
card number with an e-mail address and its corresponding e-mail 
password; and, optionally, referencing the same e-mail address 
to a bio-rhylhmically encoded password. 
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Method and System for Linking Any Instant 

MESSAGE SYSTEM AND DATA TRANSFER TECHNOLOGIES 
Background of the Invention 

rOOOlJ 1. Field of the Invention: 

[0002] This invention relates generally to a method and system for nsing a Single Nan* 
tostant Messaging Protocol (SNIP) that uses the universal nanaespace of e-xnail to fecflitale pee, 
o-peer mstant message communications and/or,data communication among users connected to 
different networks; and using similar protocol to authenticate use of a credit card. 
(0003) 2. Description of the Related Art: 

100041 EV6n logical advances in the Internet, there still are many problems 

assorted with it. For instance, instant messaging is a type of electronic communication that 
enables user to chat instantly with one or more individual via conmuter. Typically, me mstant 
messagmg system alerts the user whenever somebody on foe user's private list is online The 
user can then initiate a chat session with that particular individual. Unfortunately, there are 
several competing instant messaging systems and no standard protocol. As a result, for a user to 
send mstant messages to another user, both users must use the same instant messaging system In 
other words, two users using different instant messaging systems cannot communicate with each 
ate. Still another shorteonring with the present instant message communication is that each 
mdrvrdual instant messaging service maintains separate and linmed.apacity namespace of which 
two partes need to be a member to communicate via instant messages. Thus, this too makes 
mstant messaging across multiple networks difficult, if not impossible. 
[0005] Yet another problem associated with the Internet is fraudulent use of a credit card. 
For mstance, just about anyone with credit card information can purchase an item through the 
Internet without the permission of the owner of the credit card. As such, many credit card users 
are reluctant to use the credit card through the Internet in fear of the credit card information being 
stolen when used through the Internet. 

[0006] Therefore, there is a need for a method and/or system to allow users to facilitate peer- 
to-peer mstant message communication among users connected to different instant messaging 
systems andaUowprotection against fraudulent use of credit cards through fce Internet ' 

Brief Summary of the Invention 

10007] One aspect of the present invention is to provide a method and system to facilitate 
peer-to-peer mstant message connmmications among users connected to different (and the like) 
mstant messaging systems. To do this, the present invention provides a Single Name Instant 
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Messaging Protocol (SNIP) that uses the universal namespace of e-mail to 'fecilitate peer-to-peer 
instant message communications among users connected to different networks. Under this 
protocol, a user can register its e-mail address and Internet Protocol (IP) address with a SNIP 
server. If another member wishes to communicate with a target user by instant messages, the 
member sends an authentication request to the SNIP server. The SNIP server forwards that 
authentication request to the target user's e-mail server, such as POP3, a commonly used e-mail 
protocol, detailed in RFC 1939. If me SNIP server receives proper acknowledgment from the 
user's mail server, the target user is registered with the SNIP server as being "online." Then 
instant message communication can commence. Alternatively, the present invention may use 
IMAP (Internet Message Access Protocol), another commonly used e-mail protocol, to 
authenticate a user. For protocols other than POP and MAP, authentication may be 
accomplished in a slightly different manner. 

[0008] By way of background, authentication may be defined as the process of proving the 
identity of an individual, usually based on a user name andVor password. Moreover, POP may be 
generally defined as a protocol used to retrieve an e-mail from a mail server. Most e-mail 
applications (sometimes called an e-mail client) use me POP protocol, although some can also 
use the newer MAP (Internet Message Access Protocol). There are two versions of POP. The 
fort, called POP2, became a standard in the mid-80's and requires SMTP (Simple Mail Transfer 
Protocol) to send messages. The newer version, POP3, can be used with or without SMTP, 
which is a lower level mail protocol for sending e-mail messages between servers. Most e-mail 
systems that send mail over the Internet use SMTP to send messages ftom one server to another, 
the messages can then be retrieved with an e-mail client using either POP or MAP. In addition, 
SMTP is generally used to send messages from a mail client to a mail server. For this reason, a 
user generally needs to specify both the POP or MAP server and the SMTP server when the user 
configures its e-mail application. 

[0009] With the SNIP system, substantially all, if not all, users registered with the SNIP 
server have the ability to receive instant messages through their e-mail address or IP number 
regardless of the ISP (Internet Service Provider) or online service to which Ihey belong. 
[0010] Another aspect of the present invention is to use me e-mail address verification of 1he 
Single Name Instant Messaging protocol to authenticate a user over me Internet to provide online 
feud protection when using a credit card. To do so, a method and system according to one 
embodiment of the present invention includes a database that references a credit card number 
with an e-mail address and its corresponding e-mail password; and, optionally, referencing the 
same e-mail address to a mo-rhythmically encoded password. For instance, once the credit card 
number is registered with the corresponding e-mail address, and e-mail password, and optionally 
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Brief Description of the Drawings 

HM3J A^^aoripuoooftopreferredambodrroeMofto 
reference to fee accompanying drawings; 

[0014, FIG lis an exemplary flow chart mustrating the procedure for a SNIP client to log 
onto and authenticate with the SNIP server; 

[0015] PIG. 2 isanexemplary flow chart fflustrating the procedure for a SNIP chent to look 
up another user with the SNIP server; 

[00161 HG. 3 is an exemplary block diagram of a SNIP server facilitating peer-to-peer 
nrtwoii^ 6 ^ 88 ^' 6 COnn ^ U ^° a ^ 0n ^ Sl3 ^ ai d&te communication among users connected to different 

[0018] PIG. 5 is an exemplary flow chart for an automation procedure. 
Detailed Description of the Preferred Embodiments 

100191 ™* de8Cripti0n i8 °ot to be taken in a Imuting sense, but is made merely for me 
V^«W-am*B-«!^«+*^ Ihe section tMes and overaJl 
orgumzanon of the present detailed description are tor the purpose of convenience only and are 
not mtended to limit the present invention. 
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[0020] One aspect of the present invention is to provide a Single Namespace Instant 
Messaging Protocol (SNIP) to facilitate peer-to-peer, client-to-server instant message 
commutations and/or data communication among users connected to different networks. One 
of the advantages with SNIP is that it uses existing networks for authentication hy using existing 
universal namespace, i.e., the e-mail address of users. Since all of these networks are already 
established, me present invention uses the existing foundation for authentication and registration. 
For example, by using POP3 protocol RFC #1725, SNIP can authenticate a user from any 
network that has an Internet e-mail address. After the server authenticates and registers the 
user's e-mail address and IP, then the client is ready for peer-to-peer and/or cUent-to-server 
and/or three-tier communications. 

[0021] In the following description, the term "client" generally denotes a software and/or 
source code mat handles interaction between a user and a server, and back and forth. For 
example, a client, sometimes called a client/server architecture, may be a network architecture in 
which each computer or process on the network is either a client or a server. Servers are 
computers or processes dedicated to managing disk drives (file servers), printers (printer servers), 
or network traffic (network servers) and the like. Put differently, clients are PCs or workstations 
on which users run applications. Clients rely on servers for resources, such as files, devices, and 
even processing power. Another type of network architecture is known as a peer-to-peer 
architecture because each node has eqmvalent.responsfoilities. Bom chent/server and peer-to- 
peer are widely used, and each has unique advantages and disadvantages. Client/server 
architectures are sometimes called two-tier architectures. In particular, an e-mail client may be 
an application that runs on a personal computer or workstation and enables the user to send, 
receive and organize e-mail. It's called a client because e-mail systems are based on chent/server 
architecture as discussed above. Mail is sent from many clients to a central server, which 
reroutes the mail to its intended destination. 

[0022] There is also another type of client/server architectare with three well-defined and 
separate processes, eachrunning on a different platform: (1) the user interface, wMchruns on the 
user's computer (the client); (2) the functional modules that actually process data. This middle 
tier runs on a server and is often called the application server, and (3) a database management 
system (DBMS) foat stores the data required by the middle tier. This tier runs on a second server 
called the database server. This three-tier design has many advantages over traditional two-tier 
or single-tier designs, foe chief ones being (a) the added modularity makes it easier to modify or 
replace one tier without affecting the other tiers; and (b) separating foe application functions from 
the database functions makes ft easier to implement load balancing and scalability. 
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aoWledge to aothenocation request Hem, if a SNtP server recei™ an "soT from to nse* 
POPS server, ton to protocol 10 proceeds to stop 26, where to user's e-mail address and IP 
number are registered with to SNIP server as being ON-LINE 

[0024J °»<tootorhan4iftoSl®ser,erreceiv=oaW ft omtoto OT 'sPOP3ser ra 
ton to antonnoanon be. frdfod and wffl retorn to stop 20 for a re-autouucairon procedure' 
Tie user's POP3 may no, acknowledge to uutonticauon request for many masons, such as to 
IP address no. mntohmg, wxong user's nmne, wrong e-mail addmes, wrong password, wrong 
se^fortoe^ailserver.andtoserveruo.rennmg. Howev^ifconectpammetomareinpo. 
for to user, ton to POP3 server should acknowledge to autontatta request from the SNIP 
server, r.e., return an "ack" to the SNIP server. 

10025] With the above SNIP authentication procedure and the SNIP protocol 10 all 

* ™* ^ *»* t0 »*» *— messages 

through the, e-mail add ress and/or IP number, regardless of which ISP or online service to 

whxch they belong. The instant messaging, for example, now takes place over peer-to-peer' 
***** chent-tc-server (two-tier), and three-tier connections, freeing the SNIP server 
fiom ack/'«nack,» and control protocols. Tbat is, once authenticated, to make a peer-to-peer 
connection, for example, the first client drops the link with the SNIP server automatically and 
tnes to ^ a socket with the second client using the IP address and/or e-mail address 
mformation for the second client gotten from the SNIP server. 

[0026] By way of background, a socket in UNIX and some other operating systems may be 
^described as a software ^teoaaDrt-^^to.^^ fc 

^ fOT ^ a Pr0gram CaD md ™™ TCP/IP usages by opening a socket and 
-dnrg and wntmg data to and from the socket This simplifies program development becau*. 
the programmer need only worry about mandating the socket and can rely on the operating 
system to actually transport messages across the network correctly. Moreover, by using POP3 
for the authentication procedure, for example, it eliminates the end user from having to go 
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through a lengthy registration process. This also ensures that SNIP uses a single namespace, and 
is available to anyone in the world that has an e-mail address mat uses POP3 or other useable 
protocols. Of course, other connection methods known to one skilled in the art may be used with 
• the present invention. 

[0027] FIG. 2 illustrates an exemplary procedure for a SNIP client to look up another user 
' with a SNIP server. To do so, the client logs on. The first time the client runs or the user 
intentionally decides to change its identity, the SNTP server may prompt the client and/or user for 
its POP3 e-mail name and password. A POP3 connection may be established with its e-mail 
server, and the e-mail name and address may be verified This information can then be saved as 
a new "client profile," to which buddy / ignore / and other date can be added - a nickname, for 
example. Once the user has logged onto the client, me client may establish a connection to the 
server, sending the previously validated e-mail name and the IP address of the server on which 
the client is running. 

[0028] Moreover, besides the e-mail and the IP address, the connection may be established 
with a GUID (Globally Unique ID) to ensure mat the client is who the user says it is. GUID may 
be generally defined as an algorithm mat works off a MAC (Machine Address Code) address, 
which is a government number given to every Ethernet card or hub on the network. That is, users 
that have Ethernet cards have a unique number so mat no other user can have the same GUID. 
With the present invention, once the client comes online, a GUID may be pinned to die client, 
which is then sent to the SNIP server, along with, the IP address and/or e-mail address, to 
authenticate. Then, after a peer-to-peer connection is made between two or more clients, the 
GUID may be used as a secret code between me clients during that session. So if one of the 
clients drops out of the connection, either intentionally or unintentionally, and a different client 
by chance is assigned the same IP address of the dropped client, the different client cannot be 
connected to the session, although the IP address may be the same as the one given by the SNTP 
server because the GUID of the different client does not match the GUID of the session. 
[0029] For example, if a first client and a second client are online and the second client, for 
some reason, drops off and Hies to come back online, the second client may get a new IP address; 
therefore the first client is unable to connect to the second client because of the different IP 
address now assigned to the second client Moreover, if by chance a third cEent, who was not 
originally connected to the first client, is now assigned to the IP address which previously 
belonged to the second client, the first client cannot connect to the third client because the GUID 
doesnotmatoh. This way, the first client is not fooled into thinking that me third client is the 
second client Rather, to reconnect to the second client either the first or second clients need to 
re-authenticate to establish toe connection. 
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request, then the receiving user can choose to send a short rejection message along with the 
rejection. 

[0034] Still another embodiment of Ihe present invention is to transfer data between 
connected clients. That is, once a conversation has begun, the two clients may send messages 
back and forth. The sending client may establish a connection, send the data, wait for 
acknowledgment, and then disconnect A "message header" may precede the message data, 
describing the type and size of the message data, the time when it was sent, and a checksum for 
verifying message integrity. "Plain Text," "Formatted Text," "Files," or "Voice" are some 
examples of formats or data that may be transferred with the present invention. Of course, other 
data may be transferred using the present invention as known to one skilled in the art 
[0035] Yet another embodiment of fhe present invention is to provide a periodic pinging of 
"buddies." For example, the client can establish a list of "buddies" that the client wants to track. 
The client will periodically try to determine if each "buddy" is on line. To check, fhe client may 
try to connect to the target client via the locally cached IP address. If fhe ping foils, it may 
request a new IP from the SNIPS server, and update its local cache and try again if it gets one. If 
the client-to- client "ping" connection is successful, then fhe user is shown as "on line." If 
neither succeeds, the person is shown as "off line." 

[0036] Still another alternative embodiment of the present invention is to enforce the 
"ignore." In this embodiment, the client may cache a list of e-mail names and/or IP addresses 
which the client has chosen to ignore. Having done so, all connection requests from the "ignore" 
list of e-mail names or IP addresses may be automatically rejected. In particular, the option of 
ignoring by IP addresses would prevent a user in foe "ignore" list from simply changing its e- 
mail name and bypassing the ignore list. Furthermore, to prevent users using different IP and e- 
mail names from getting through, a secondary GUED or GUID for that session may be used to 
enforce foe "ignore." 

[00371 FIG. 3 illustrates by way of example block diagrams representing the interaction 
among the main SNIP server 50, SNIP clients 52, and SNIP servers 54, Wifo regard to the main 
SNIP server 50, it works as a regular SNIP server, but wifo foe added responsibility of directing 
traffic for other SNIP servers. That is, the main SNIP server 50 handles requests similar to 
mtetnic and the Whois structure. However, these requests may be searching for SNIP servers. 
For example, for an ISP to register, a SNIP server may fill out the forms to update the SNIP 
central database. ItriayalsorequteaproofofownersMpoffoedomam. When a client searches 
for a specific user, it first checks foe main database. If the main database does not have that 
person registered, the client then tries to find foe secondary SNIP server for that domain name, if 
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feat person is not register* there, then that person is offline. So the main SNIP server keeps a 
database of current users as well as a database of registered SNIP servers 
[0038] Moreover, the main SNIP server may be implemented as a muln-threaded application 
The mam thread may be idle, i.e., waiting for TCP/IP connections on the designated server port' 
Upon receiving a connection, me server may spawn a child thread to handle the transaction, then 
return to its wait state. The child thread may then handle the transaction with the connecting 
chent, wbch may be one of two types, a Agister* transaction, or a "get address" transaction m 
general, the register transaction is where the client sends an e-mail name and IP address so mat 
the server may add/update its database of registered clients. This allows the server to 
acknowledge the transaction and disconnect In general, the get address transaction is where the 
chent sends an e-mail name so that the server may look up the e-mail name in its database and 
return the associated IP address (or an error code), then disconnect 

10039] Still further, the statistics on each transaction may also be recorded in the database so 
that a separate administration tool may show the statistics. This allows the a<mnnistrative tool to 
detect SPAM attacks on me server, and automatically disable the connections from the offending 
address. e 

I0040J Asffl^taHG. Immmfiw^Htm^^ ^ 
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connection attempts. 

[0041] With regard to a standard SNIP server 54, me bulk of these servers are directed at 
authentication and registration. Moreover, these servers are. responsible for mamteining a 
^eofusersmatarecurr^flyonline. For example, the client may ping me server in a 
specrfied amount of time. If the server does not receive a ping from the chent in a specified 
amount of time, then that user's registration may be deleted. 

r0042I With regard to the SNIP client 52, it may take on most of the msponsibflities of the 
SNIP protocol and architecture. It may be responsible for negotiating the protocol in its entirety 
It plays the main role in the successful execution of the architecture. It handles the other half of 
the authentication and registration scheme; and may also be responsible for the peer-to-peer 
communications. It creates ignore, and buddy files on the client's nuchme, as wefl as making 
sure mat users on the ignore list are ignored and users on the buddy list are checked for online 
registration. 

[0043] The clientmay handle requests for communications from other clients. The user has 
the abrhty to deny communication requests from other clients or accept mem at any time. It is 
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also the client's responsibility to negotiate toe search protocol and complete the searching for 
another user's connect information from various SNTP servers. It is responsible for pinging the 
SNTP server to tell the server it is still online and available for communication with other clients. 
Since the protocol is written in XML, it can be updated easily and new tags can support multiple 
forms of data, making SNTP clients suitable for voiceover TP and other data messaging 
technologies. The clients should be expandable and meld with other technologies easily as long 
as the underlying SNTP protocol remains intact and the authentication process is adhered to. 
[0044] FIG. 4 illustrates by way of example a message board to facilitate peer-to-peer instant 
message communications and/or data communication. For example, the top text box may be for 
conversation history. The bottom box may be where the user types in the next message it is 
going to send. Moreover, multiple conversations may be handled by a tab control. There may be 
an indication when there has been an activity in a lab where the user is not viewing. Although a 
plain text conversation is illustrated, other textual conversation may look similar. Note mat 
binary data, like files or voices or the net, may need less extensive UI (User Interface). 
100451 Another embodiment of Ihe present invention is to provide a method and system using 
SNTP that verifies that toe rightful owner of a credit card is making an online purchase. To do so, 
there is a registration process and an authentication process. In the registration process, a simple 
web form may be provided to enter the credit card information: (1) the credit card number, (2) e- 
mail address associated with me credit card number, (3) e-mail password for Ihe e-mail address 
associated with toe credit card number, and (4) optionally, bio-password to take a reading of the 
user's bio-rhythms for the e-mail password Once the credit card owner has entered the above 
data and re-enters toe e-mail password enough to get a bio-reading of toe owner, the data and the 
bio-reading is sent to a server for storage and registmtion is complete. Alternatively, many 
different cryptography techniques and encryption algorithms known to one skilled in the art may 
be used in toe present invention Once the user has entered this data, the data is sent to the 
verification server. 

[0046] FIG. 5 illustrates by way of example toe authentication process of toe present 
embodiment. First, the e-mail address, e-mail password, toe bio-rhythmic date, and toe credit 
card number are collected as user data 90. This may be done with a combination of regular 
HTML form elements. Internet technologies, known to one ordinarily skilled in the art, such as 
Active X and or Java, may be used to ascertain toe bic-mythmic password logic and read and 
encode a user's bio-rhytoms. The second step is to send toe user-data, mchding bio-rhythmic 
password data, to toe verification server for processing. The server may follow a protocol that 
has three specific tasks: (1) match toe e-mail address to toe credit card number given 92; (2) 
authenticate the user's e-mail address by receiving an authentication from toe SNTP protocol 96; 
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What is claimed is: 

1. A method for authenticating a user to facilitate an instant data communication, 

comprising the steps of: 

receiving an authentication request for a user to a single namespace instant 

messaging protocol (SNIP) server, 

forwarding the authentication request to the user's e-mail protocol; and 

receiving a response from the user's e-mail protocol, wherein: 

if the response is an ack, then registering the user's IP number with the SNIP 

server as being ONLINE; and 

if the response is a naclc, then not registering the user; 

whereby all users registered with the SNIP server can receive instant data 
communication through their e-mail address and/or IP number regardless of Internet 
Service Provider that the user belongs to, where the communication takes place over a 
peer-to-peer, client-to-client, or three-tier connection. 

2. A method according to claim 1 , wherein if the response is an ack, then: 
dropping a link with the SNIP server, 

opening a socket using the user's IP number to make peer-to-peer communication. 

3 . A method according to claim 1, wherein the user's e-mail protocol is a Post Office 
Protocol (POP). 

4. A method according to claim 3, wherein the POP is a POP3. 

5. A method according to claim 1, wherein: 

If the response is an ack, then registering the user' s e-mail address with the SNIP . 

server as being on-line. 

6. A method according to claim 1, wherein the authentication request is forwarded to 
the user's e-mail protocol using RFC number 1725. 

7. A method according to claim 1 , wherein the SNIP server keeps user data. 

$. A method according to claim 1, wherein the user data includes: 
e-mail name; 
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IP address; 

date of the last connection; and 
time of the last connection. 

10. A method according to claim 9, wherein the coition data includes- 
originating IP address; 
count of connections; 
date of last connection; 
time of last connection; and 

average milliseconds between the connections attempted. 

11. A method according to claim 1, wherein the user's e-mail protocol is an Want 
Message Access Protocol (IMAP). 

12 Am ^-^to^^ 
to-peermstant message communication. apeer 

voio^rp. ^ nw *kod according to ciahr, wteek fc ^ ^ . 
M. A method according lo claim 1, wherein: 

^Jr;/c^ fcraoBMtoI "* wto ^ tem ^ to ~^ 

who*: — — dolose, 

-hen hiding thesteps'of: server's database has the e-mail address of the desired user. 
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the client receiving the IP address of the desired user stored within 

the SNIP server's database; and 

fee client communicating directly wife fee desired user by opening 

a socket using fee desired user' s IP address; 

if fee SNTP server's database does not have fee e-mail address of fee 

desired user, then further including fee steps of: 

fee SNIP server notifying fee desired user of fee incoming request 
for connection by sending an e-mail notification to fee desired user's e-mail address; and 

notifying fee client feat fee desired user is not available. 

16. A method for authenticating a credit card used to make an online transaction, 
comprising: 

registering an owner credit card number, an owner e-mail address associated wife 
the owner credit card number, and an owner e-mail password for fee owner e-mail address; 

checking an e-mail address provided for using fee owner credit card number 

against fee owner e-mail address; 

checking an e-mail password provided for using fee owner e-mail address against 

fee owner e-mail password; and 

verifying an online authentication if fee checking of e-mail address and fee e-mail 
password match fee owner e-mail address and owner e-mail password, respectively. 

17. A method according to claim 16, further including: 

recording a pattern of fee owner e-mail password for an owner of fee owner credit 

card number, 

checking an pattern of an e-mail password provided for using fee owner e-mail 
address against the recording of fee pattern of fee owner e-mail password; and 

approving fee online transaction if fee checking of fee pattern matches. 

18. The method according to claim 16 wherein fee partem is abio-rhyfemic pattern. 

19. The method according to claim 16 further including fee steps of: 

forwarding fee e-mail address to a Single Namespace Instant Messaging Protocol 
(SNTP) server, 

checking fee SNIP server's database for fee e-mail address; wherein: 
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if the SNIP server's database has the e-mail address, then the verification 
server receiving an acknowledgement 

compris^ Am6 * 0df0ra ^^^ 

registering a credit card nurnber and a first e-mail address associated with the 
credit card number, and a first pattern of the first e-mail address; 

checking a second e-mail address provided for using the credit card number 
against the first e-mail address; 

, a second pattern of the second e-mail address provided for using the 

credit card number against the first pattern of the first e-mail address; and 

seen * , 7^ " * * e to address is identical to the 

are U ^ A ^ t0 ^ " ^ * ** - * e — pattern 

are bio-rhythmic patterns. F 
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(57) Abstract: The present invention provides a method 
and system to facilitate peer-to-peer instant message 
communications among users connected to different instant 
messaging systems. To do so, the present invention provides 
a Single Name Instant Messaging Protocol (SNIP) that uses 
the universal namespace of e-mail to facilitate peer-to-peer 
instant message communications among users connected to 
different networks. Another aspect of the present invention 
is to use the Single Name Instant Messaging protocol to 
authenticate a user over the Internet to provide online fraud 
protection when using a credit card. To do so, a method and 
system according to one embodiment of the present invention 
includes a database that references a credit card number with 
an e-mail address and its corresponding e-mail password; 
and, optionally, referencing the same e-mail address to a 
bio-rhythmically encoded password. 
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